1. Field of the Invention
The present invention relates generally to graphics systems and, more particularly, to graphics system performance optimization techniques.
2. Related Art
Computer graphics systems are commonly used for displaying two- and three-dimensional graphical representations of objects on a two-dimensional video display screen. Current computer graphics systems provide highly detailed representations and are used in a variety of applications.
In a typical computer graphics system, an object or model to be represented on the display screen is broken down into graphics primitives. Primitives are basic components of a graphics display and include, for example, points, lines, triangles, quadrilaterals, triangle strips and polygons. Typically, a hardware/software scheme is implemented to render, or draw, the graphics primitives that represent a view of one or more models being represented on the display screen.
Generally, primitives of a three-dimensional object to be rendered are defined by a host computer in terms of primitive data. For example, when the primitive is a triangle, the host computer may define the primitive in terms of the X, Y, Z and W coordinates of its vertices, as well as the red, green and blue and alpha (R, G, B and xcex1) color values of each vertex. Additional primitive data may be used in specific applications. Rendering hardware interprets the primitive data to compute the display screen pixels that represent each primitive, and the R, G and B color values for each pixel.
A graphics interface is typically provided to enable graphics applications located on the host computer to efficiently control the graphics system. The graphics interface provides specific commands that are used by a graphics application executing on the host computer to specify objects and operations, producing an interactive, three-dimensional graphics environment. Such a graphics interface is typically implemented with software drivers.
For example, the OpenGL(copyright) standard defines an application program interface (API) that provides specific commands that are used to specify objects and operations to produce interactive, three-dimensional applications. (OpenGL is a registered trademark of Silicon Graphics, Inc.). OpenGL is a streamlined, hardware-independent interface designed to be implemented on many different hardware platforms. As such, in computer systems which support OpenGL, the operating systems and graphics application software programs can make calls to the computer graphics system according to the standardized API without knowledge of the underlying hardware configuration. The OpenGL standard provides a complete library of low-level graphics manipulation commands for describing models of three-dimensional objects (the xe2x80x9cGLxe2x80x9d of OpenGL refers to xe2x80x9cGraphics Libraryxe2x80x9d). This standard was originally based on the proprietary standards of Silicon Graphics, Inc., but was later transformed into an open standard which is used in high-end graphics-intensive workstations and, more recently, in high-end personal computers. The OpenGL standard is described in the OPENGL PROGRAMMING GUIDE, version 1.1 (1997), the OPENGL REFERENCE MANUAL, version 1.1 (1997), and a book by Segal and Akeley (of SGI) entitled THE OPENGL GRAPHICS SYSTEM: A SPECIFICATION (Version 1.2), all of which are hereby incorporated by reference in their entirety.
A graphics system typically maintains state values that represent the current state of various aspects of object models. Graphics systems generally behave as a state machine; a specified state value remains in effect until it is changed by the graphics application through the issuance of an API command, also referred to herein as a graphics call, to the graphics system through the graphics software interface. Thus, all vertices are rendered in accordance with a current value of applicable state variables in the graphics system.
By providing detailed control over the manner in which primitives and their vertices are rendered in the graphics system, the graphics software interface provides software developers with considerable flexibility in creating graphics application software programs. A graphics software application may be structured in any one of many different configurations to implement a desired function or to achieve a desired result in the graphics system. For example, graphics applications may generate a different graphics call sequence to achieve the same rendering of the same model.
It is well known that some graphics call sequences and the manner in which primitives, vertices and states specified in the sequence are implemented are more efficient than others. That is, although multiple graphics applications may achieve the same rendering of the same model, certain graphics applications may, due to the contents of the graphics call sequence that they generate, cause the graphics system to perform unnecessary operations, or to perform certain operations in a manner that requires greater overhead than is otherwise necessary.
Generally, graphics call sequences generated by a graphics application are stored in a memory prior to being executed by the graphics system. When stored for execution by the graphics system, such graphics call sequences are commonly referred to as a display list. The memory dedicated to the temporary storage of these graphics call sequences is commonly referred to as a display list memory. In conventional graphics systems, overhead is associated with the storage of these graphics call sequences in the display list memory (xe2x80x9cstorage overheadxe2x80x9d). For example, when generating a single graphics primitive using the OpenGL graphics library, a glBegin() graphics call is first issued to indicate the start of a particular type of the primitive. The glBegin() graphics call is followed by an appropriate number of glVertex() graphics calls specifying the vertices of the identified primitive, followed by a glEnd() graphics call to indicate the end of the primitive. A number of different graphics calls may be located between a glBegin()/glEnd() graphics call pair. Such graphics calls include graphics vertex calls as well as graphics calls that set state variables. All such graphics calls are referred to herein as vertex-related graphics calls. The glBegin()/glEnd() pair and all graphics calls interposed between the two are collectively and generally referred to herein as a primitive data set. Other graphics calls that do not occur between a glBegin() and glEnd() graphics call are referred to herein as non-vertex-related graphics calls. One particular type of non-vertex-related graphics call are graphics calls that alter the modal state of the graphics system. A primitive data set representing, for example, a single independent triangle, includes a glBegin() call, followed by three glVertex() calls to generate the three vertices of the triangle primitive, followed by a glEnd() call. As a result, five graphics calls or commands are processed to generate a single triangle primitive. All five of these commands in the primitive data set are stored in the display list memory. A display list generated by a typical graphics application often contains millions of graphics primitive data sets. The overhead associated with the storage of a large number of primitive data sets in the display list memory can impose a significant burden on the efficiency of the graphics system.
Furthermore, when a primitive data set is executed, execution of the glBegin() command at the beginning of each primitive data set typically incurs some execution overhead by the graphics system, such as verifying the validity of the identified primitive, and configuring the graphics hardware to render the specified primitive. Thus, the total execution overhead associated with executing the glBegin() commands in a typical graphics call sequence can be significant.
Some graphics system optimization schemes perform post-processing of the display list subsequent to its generation by an application program. Such post-processing techniques generally require that primitive data for all graphics calls which are to be optimized have been generated and stored in the display list memory prior to the performance of the optimization techniques. Once the graphics call sequence is stored in the display list memory, such conventional post-processing techniques analyze the stored display list to determine if it can be optimized. Generally, such conventional post-processing techniques adversely affect the performance of the graphics system. The impact of such processing on run-time operations is so great that such techniques are sometimes performed off-line to analyze the performance of, and identify potential improvements to, the graphics application. Furthermore, removal from the display list of unnecessary graphics calls causes memory fragmentation of the display list memory, adversely impacting the performance of the graphics system.
What is needed, therefore, is a system and method that optimizes graphics call sequences by reducing the storage and/or execution overhead associated with the generation, storage and execution of such sequences.
Illustrative aspects of the present invention are directed to apparatuses and methods used in a graphics system that includes a display list memory to store graphics calls to be executed. The disclosed and other aspects of the present invention optimize an original graphics call sequence that includes a plurality of graphics primitive data sets generated by a graphics application program in accordance with a graphics application program interface (API), generating an optimized graphics call sequence to be stored in the display list memory. The method comprises a step of: a) optimizing the original graphics call sequence to produce the optimized graphics call sequence without storing the original graphics call sequence in the display list memory; and b) storing the optimized graphics call sequence in the display list memory for subsequent execution by the graphics system. In one embodiment, a plurality of primitive data sets of a particular primitive type occurring sequentially within the original graphics call sequence are coalesced by the invention into a single primitive data set of the same primitive type in the optimized graphics call sequence. In another embodiment, primitive data sets that define the same type of primitive are coalesced into a single primitive data set of the particular type until a primitive data set that is not of the particular primitive type appears in the original graphics call sequence. In a still further embodiment, the original graphics call sequence is optimized by removing graphics calls from the original graphics call sequence that do not effect a rendering of the original graphics call sequence in the graphics system. The optimized graphics call sequence causes a same rendering in the graphics system as the original graphics call sequence.
In one specific embodiment of the present invention, the API is an OpenGL API, and each of the plurality of graphics primitive data sets in the original graphics call sequence comprises a glBegin() graphics call, a glEnd() graphics call, and at least one graphics vertex call occurring between the glBegin() and the glEnd() call. In certain embodiments which implement the OpenGL API, all glBegin() and glEnd() graphics calls are removed from the primitive data sets in the original graphics call sequence which are to be coalesced, other than a glBegin() graphics call occurring in a first primitive data set and a glEnd() graphics call occurring in a last primitive data set in the original graphics call sequence. This results in a coalesced graphics primitive data set corresponding to the coalesced primitive data sets in the original graphics call sequence.
The above and other aspects of the present invention may be implemented in many different embodiments. For example, aspects of the present invention may be implemented in a computer readable medium or in a system. For example, one aspect of the present invention is directed to a graphics call sequence optimizer, for use in a graphics system that includes a display list memory to store graphics calls to be executed. The optimizer optimizes an original graphics call sequence including a plurality of graphics primitive data sets generated by a graphics application program in accordance with a graphics application program interface (API), generating an optimized graphics call sequence for execution by the graphics system. The optimizer is configured to optimize the original graphics call sequence to produce the optimized graphics call sequence without storing the original graphics call sequence in the display list memory. In one embodiment of the present invention, the graphics call sequence optimizer is configured to coalesce graphics primitive data sets within the original graphics call sequence to generate a corresponding single graphics primitive data set in the optimized graphics call sequence that causes a same rendering in the graphics system as the original graphics call sequence. In another embodiment of the present invention, the graphics call sequence optimizer is configured to coalesce a series of graphics primitive data sets of a particular primitive type occurring sequentially within the original graphics call sequence into a single graphics primitive data set of the particular type in the optimized graphics call sequence. In a further embodiment of the present invention, the graphics call sequence optimizer is configured to coalesce graphics primitive data sets of the particular type into a single graphics primitive data set of the particular type until a graphics primitive data set that is not of the particular type appears in the original graphics call sequence.
In one embodiment of the present invention, the API is the OpenGL API, and each of the plurality of graphics primitive data sets in the original graphics call sequence comprises a glBegin() graphics call, a glEnd() graphics call, and at least one graphics vertex call between the glBegin() graphics call and the glEnd() graphics call. In another embodiment of the present invention, the graphics call sequence optimizer is configured to remove all glBegin() and glEnd() graphics calls from the original graphics call sequence other than a glBegin() graphics call occurring in the first graphics primitive data set in the original graphics call sequence and a glEnd() graphics call occurring in the last graphics primitive data set in the original graphics call sequence.
The present invention overcomes the above and other drawbacks to conventional graphics system optimization techniques. For example, one aspect of the present invention is directed to a method and apparatus for optimizing an original graphics call sequence generated by a graphics application in accordance with a standard graphics application programming interface (API), such as the OpenGL API without storing the original graphics call sequence in the display list memory. The resulting optimized graphics call sequence causes the same graphics rendering to occur when provided to the graphics system as the original graphics call sequence. Because the graphics call sequence consists of calls made according to a standard API, the application program need not be modified to take advantage of the optimization techniques. In fact, optimization occurs entirely transparently to the application program.
Other features and advantages of the invention will become apparent from the following description and from the claims.